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1.0 INTRODUCTION 

1.1 IDENTIFICATION OF VOLUME 

This is the Configuration Management Plan for the AdaNet Repository Based 
Software Engineering (RBSE) contract. This document establishes the requirements 
and activities needed to ensure that the products developed for the AdaNet RBSE 
contract are accurately identified, that proposed changes to the product are 
systematically evaluated and controlled, that the status of all change activity is 
known at all times, and that the product achieves its functional performance 
requirements and is accurately documented. 

1.2 SCOPE OF VOLUME 

The Configuration Management policies and processes documented in this plan are 
applicable to the GHG Corporation personnel working on the AdaNet RBSE 
contract. 

1.3 PURPOSE AND OBJECTIVE OF VOLUME 

This document defines the configuration management policies, plans, and 
procedures to be utilized by GHG Corporation personnel in satisfying the 
requirements of the Repository Based Software Engineering (RBSE) Program. 

1.4 STATUS AND SCHEDULE 

This document shall be updated, and new revisions shall be published, as program 
plans become available from the other contractors and changes in the requirements 
are deemed necessary to meet the interfacing needs between the contractors working 
on the AdaNet RBSE contract. 
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2.0 RELATED DOCUMENTATION 

2.1 PARENT DOCUMENT 

This Configuration Management Plan derives its parentage from the Program 
Management Plan of the Repository Based Software Engineering (RBSE) Program, 
Document Number RBSE-FD-PO-003-1, dated July 31, 1991. 
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3-0 RESOURCES. BUDGETS. SCHEDULES. AND ORGANIZATION 

Refer to the Program Management Plan of the Repository Based Software 
Engineering (RBSE) Program for information related to the resources, budgets, 
schedules, and organization. 

3.1 EQUIPMENT 

A computer system and data base handler capable of storing, under controlled access, 
all company and vendor produced source code is required. The computational 
system shall be capable of generating reports as required by configuration 
management personnel. The format and content of the reports shall be capable of 
being tailored by configuration management personnel with a minimum of 
training. The computational system shall be capable of receiving input data, in the 
form of page inputs, from remote terminals. Security provisions shall be in place to 
ensure the integrity of the data and source code under configuration control. The 
security system shall be capable of preventing unauthorized modification of the 
source code and data. 

3.2 MATERIALS, FACILITIES, AND OTHER RESOURCES 

At minimum, normal working equipment shall be available, including, but not 
limited to, the following: 

a) Desks, chairs, and bookcases 

b) Filing cabinets sufficient to store one program's change related papers 
in each 

c) Telephones 


3-1 


RBSE-CMP-00001 


Configuration Management Plan 


Configuration Management Process Overview 


4.0 CONFIGURATION MANAGEMENT PROCESS OVERVIEW 

4.1 INTRODUCTION 

Configuration Management is the discipline that applies technical and 
administrative direction and surveillance to: 

a) Identify and document the functional and physical characteristics of a 
configuration item, 

b) Control changes to those characteristics, and 

c) Record and report change processing and implementation status 

As such, the discipline of configuration management typically includes the 
functions of identification and release, change control, status accounting, and the 
preparation and performance of configuration audits. Configuration Management is 
thus the means through which the integrity and continuity of the design, 
engineering and cost trade-off decisions made between technical performance, 
producibility, operability, and supportability are recorded, communicated, and 
controlled by the program and functional managers for a given program or project. 

A more detailed description of the process and related flow diagrams can be found 
in Section 5.0 and Appendix I to this plan. 

4.2 CONFIGURATION IDENTIFICATION AND RELEASE FUNCTIONS 
4.2.1 Configuration Identification Function 

Configuration Identification occurs in ever increasing levels of detail from the 
initial functional and physical performance requirements, specifications, and 
characteristics established by the engineering staff for a given product. As the 
contractually required deliverable document requirements and specifications are 
received from engineering, they are assigned a unique identification number and 
are placed under configuration control. 

Configuration Identification numbers shall be assigned to all documentation and 
source code developed or modified by GHG personnel. Items purchased by GHG for 
use on this contract (Operating Systems, computational equipment. Editors, etc.) 
shall be identified and placed under configuration control. 

Once assigned, the numbers will not be reassigned to any other engineering 
document or items of hardware or software. 
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4.2.2 Configuration Release Function 

Internal release of design and development documents, as well as Configuration 
Units (CUs) of software and hardware, occurs prior to official authentication of the 
documents or CUs. Internal release requires GHG CCB review and approval. 
Authentication (customer approval) of configuration items occurs at predetermined 
milestones in the contract. Typically, development and high-level design 
documents are authenticated by the customer at Preliminary Design Review (PDR). 
Detailed design documents are authenticated at Critical Design Review (CDR). 

4.3 CONFIGURATION CHANGE CONTROL FUNCTION 

Change control exists for the protection of both the contractor and the customer by 
establishing a means of formally communicating the need for a change as well as 
the review and approval or disapproval a proposed change. This approach ensures 
the accurate, effective communication of changes to requirements and specifications 
and is needed to ensure that the product meets the customer's changing needs and 
the contractor's business requirement to recover costs involved in meeting the new 
requirements. 

Once the formal identification for a configuration item has been established, all 
proposed changes to that identification are systematically evaluated to ensure 
traceability, contain costs, schedule future release activities, and provide for the 
development of a quality product. 

Configuration change control involves the use of a Configuration Control Board 
(CCB). CCBs exist at both the contractor and customer levels. Changes to 
configuration items not yet delivered to the customer are evaluated within the 
contractor CCB. Items that have been delivered or authenticated by the customer 
require approval by the contracting agency's CCB as well. 

4.4 CONFIGURATION STATUS ACCOUNTING FUNCTION 

As new identification data is made available or changes to existing configuration 
data are proposed, the status of the changes are tracked by configuration 
management. This activity ensures visibility into the change activity and assists in 
the management of the product. 

4.5 CONFIGURATION AUDITS 

Configuration audits fall into two categories, functional and physical. Together they 
ensure that the product functions as specified and that all changes to the initial 
identification of the product have been documented. Although not contractually 
required, GHG routinely performs both FCAs and PCAs as a matter of good business 
practice and total quality management. 
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4.5.1 Functional Configuration Audit (FCA) 

The Functional Configuration Audit (FCA) is the formal examination of the 
functional characteristics’ test data for a configuration item, prior to acceptance by 
the contracting agency, to verify that the item has achieved the performance 
specified in its functional or allocated configuration identification. 

4.5.2 Physical Configuration Audit (PCA) 

The Physical Configuration Audit (PCA) is the formal examination of the "as-built" 
configuration of a unit or item against its technical documentation in order to 
establish the item’s initial product configuration identification. 
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5.0 CONFIGURATION MANAGEMENT ACTIVITIES 

5.1 CONFIGURATION IDENTIFICATION AND RELEASE 

Configuration identification occurs in ever increasing levels of detail from the 
initial functional and physical performance requirements, specifications, and 
characteristics established by the engineering staff for a given product. As the 
requirements and specifications are authenticated and approved by the customer, 
they are assigned a unique identification number and are placed under 
configuration control. 

Detailed process flow diagrams for both the identification and release functions may 
be found in Appendix I to this plan. 

5.1.1 Identification 

The level at which a configuration item number is assigned is critical for 
management visibility into the design and development activity. To ensure proper 
selection for configuration identification, the designation of a configuration item 
shall be the responsibility of engineering, with the assistance of configuration 
management personnel. Selection shall be based on complexity, size, number of 
other projects using the Cl, and contractual obligations. 

Configuration identification numbers shall be assigned to each specification, 
hardware, or software unit developed or purchased by GHG for use on this contract. 

Once assigned, the configuration item numbers will not be reassigned to any other 
engineering document or items of hardware or software. 

5.1.2 Release 

Upon completion of internal GHG engineering testing and a successful GHG CCB 
review, a Cl is ready to be placed under configuration control. CM issues a release 
notice, formal notification to all applicable organizations to inform them that the 
configuration item is available for use in design, procurement, fabrication, coding, 
integration, and test. Items placed under configuration control shall include all 
source code, documentation, and hardware developed or purchased and modified 
for the RBSE contract, as well as the specifications for those items. 

5.2 CONFIGURATION CHANGE CONTROL 

Configuration Management is responsible for ensuring that the identification and 
change status of CIs is maintained at all times. To ensure this activity occurs, GHG 
has implemented a configuration change control procedure that tracks the reasons 
for a change, approval for change activity to begin, identification of impacts on cost 
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and schedule, and the identification and evaluation of the individual changes at the 
Configuration Control Board (CCB). 

Detailed process flow diagrams for the change control process may be found in 
Appendix I to this plan. 

5.2.1 Controlled Storage and Release Management 

Upon receipt of a configuration item, configuration management personnel shall 
perform a 'receipt PCA’ to ensure that the product to be placed under configuration 
control matches its product specifications. Upon successful completion of the audit, 
the Cl shall be placed in a secure location to prevent unauthorized changes to the 
master. Access to configuration controlled items shall be restricted and only copies 
of items shall be issued for change activities. 

5.2.2 Change Control Flow 

5.2.2. 1 Initiation and Tracking of Problem Reports 

Change activity begins with a documented need for change called a Problem Report 
(PR). The documentation of the need for a change may take the form of a Review 
Item Discrepancy (RID), a Change Request (CR), or a Discrepancy Report (DR). 
Anyone may initiate a Change Request or Discrepancy Report. 

Upon receipt of a problem report. Configuration Management personnel shall 
assign the problem report a unique tracking number and shall enter the data 
received into a CM controlled tracking data base. All tracking efforts related to the 
status of the problem report shall be performed by CM personnel. 

Once the initial tracking data is entered, the problem report data is analyzed and 
evaluated by engineering for impact assessment, alternate solutions, and a list of the 
CIs that will require modification. The proposed change package is then reviewed 
by an engineering review group to ensure that the proposed change package meets 
the requirements established by the problem report. 

A summary of the proposed change is documented and entered into the CM 
tracking data base. 

5. 2. 2. 2 Engineering Change Request/Notices (ECR/Ns) 

Engineering Change Request/Notices are used to identify and document those CIs 
that must be modified to satisfy any new requirements or repair a problem. ECR/Ns 
may be initiated against either software or hardware items and their associated 
specifications. Each ECR/N shall be assigned a unique tracking number and each 
ECR/N shall be 'tied' to the reason for a change, be it a DR, RID, or CR, by means of 


5-2 


RBSE-CMP-00001 


Configuration Management Plan 


Configuration Management Activities 


the unique tracking number assigned to the report by CM. The problem report 
number shall appear on each ECR/N. 

Upon receipt of an approved ECR/N, configuration management shall issue a copy 
of the Cl from the CM controlled archives. In no instance shall the original be 
issued for change. 

Once the copy of the CM controlled Cl is made available for change, engineering 
designs, develops, implements, and tests the change. When engineering is satisfied 
that the change package is ready for incorporation into CM’s archives, the package 
shall be forwarded to the Configuration Control Board (CCB) for review. No change 
to configuration controlled items may be implemented without CCB approval. 

Upon CCB approval, the changed CIs are incorporated into the CM controlled 
archives and the package is forwarded to the initiator for recheck. If customer 
recheck of the change package is required, CM shall forward the package, with the 
modified CIs, to the agency responsible for performing the recheck. 

5.2.3 Change Documentation 

As noted above, change activity can only begin with a documented need for a 
change; a DR, CR, or RID is required. Each problem identification form shall 
contain, at minimum, data such as the following: 

a) A statement of the problem, discrepancy, or requirements change 

b) An analysis of the problem including alternate solutions 

c) A list of the CIs to be modified, including all associated specifications 
and documentation 

d) An estimate of the time required to develop, implement, and test the 
change 

For each Configuration Item listed on the problem report, an Engineering Change 
Request /Notice shall be required before CM will issue a copy of the Cl for change. 
The engineer requesting the copy of the Cl shall initiate the ECR/N. Each ECR/N 
shall contain, at minimum, the following data: 

a) The problem report number 

b) The identification of the Cl requested 

c) The current revision or change level 
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Once the proposed change has been developed and tested, a description of the 
change shall be entered on the ECR/N prior to CCB review. 

5.2.4 Change Review Process 

All proposed changes to configuration items under configuration control shall be 
reviewed and approved, or disapproved with comments, by the cognizant CCB. 

Proposed changes to items that are under CM control but not yet authenticated by 
the customer shall require GHG CCB approval prior to implementation into the CM 
controlled archives. Proposed changes to items authenticated by the customer shall 
require CCB review and approval at a level commensurate with the level of change 
requested. 

5.2.4. 1 Engineering Design Review Board 

GHG shall establish an Engineering Design Review Board to review all identified 
and documented problems and associated change packages. The design review 
board shall review each problem report to ensure that the problem is adequately 
documented, and is, in fact, a problem rather than an operator or user error. The 
design review board shall also review the analysis of the problem and the proposed 
change package to ensure the completeness and adequacy of the change. 

5. 2. 4. 2 Configuration Control Board 

All changes to configuration items under configuration control shall be reviewed by 
the cognizant CCB. Proposed changes to items that are under CM control but not yet 
authenticated by the customer shall require GHG CCB approval prior to 
implementation into the CM controlled archives. Proposed changes to items 
authenticated by the customer shall require CCB review and approval at a level 
commensurate with the level of change requested. 

The minutes for each CCB shall be recorded and retained by configuration 
management. 

The internal GHG CCB shall comprised of the following functional representatives: 

a. Configuration Manager (CCB Chairperson) 

b. Quality Assurance 

c. Engineering 

d. Program Management 

e. CM Status Accounting (CCB secretary) 

Members of other disciplines may be requested to attend on an as-required basis. 
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5.3 CONFIGURATION STATUS ACCOUNTING 

Configuration Status Accounting records shall be maintained by configuration 
management personnel. These records shall contain listings of problems reports, 
their associated engineering change request/notices, the date of initiation, 
completed development date, and approval signatures authorizing the 
incorporation of the change into the CM controlled archives. From the data 
contained in the reports, an accurate status of each proposed change, as well as the 
status of the problem report, shall be known at all times. 

5.4 CONFIGURATION AUDITS 

Configuration audits shall be performed to ensure the configuration items meet 
functional requirements (that each performs according to it’s test criteria) and to 
ensure that each Cl is completely documented. 

Although not contractually required, GHG routinely performs both FCAs and PCAs 
on deliverable products as a matter of good business policy and a means of ensuring 
a quality product. 

5.4.1 Functional Configuration Audit (FCA) 

The Functional Configuration Audit (FCA) is the formal examination of the 
functional characteristics’ test data for a configuration item, prior to acceptance by 
the contracting agency, to verify that the item has achieved the performance 
specified in its functional or allocated configuration identification. 

5.4.2 Physical Configuration Audit (PCA) 

The Physical Configuration Audit (PCA) is the formal examination of the "as-built" 
configuration of a unit or item against its technical documentation in order to 
establish the item's initial product configuration identification. 


5-5 


RBSE-CMP-00001 


Configuration Management Plan 


Support Environment Reguirements & Tools 


6.0 SUPPORT ENVIRONMENT REQUIREMENTS AND TOOLS 

Configuration Management will require computational equipment capable of 
storing, under controlled access conditions, all vendor supplied software as well as 
all software developed or purchased and modified by GHG personnel. The 
computational system shall be capable of generating status reports as needed by 
program management, quality assurance, engineering, and configuration 
management personnel. 

Report generation tools will be capable of being tailored by CM personnel with a 
minimum of engineering assistance. Reports will be generated for configuration 
status accounting and configuration identification purposes. 

Configuration status accounting reports will be capable of identifying all problem 
reports with an indentured listing of all engineering change request/ notices. 

Configuration Identification reports will be capable of generating indentured parts 
lists from any Cl level requested. 
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CCB: 

Configuration Control Board 


Q: 

Configuration Item 

— 

CR: 

Change Request 


DR: 

Discrepancy Report 


DRB: 

Design Review Board 

— 

ECR/N: 

Engineering Change Request/Notice (Form) 


FCA: 

Functional Configuration Audit 


PA: 

Problem Analysis (Form) 


PCA: 

Physical Configuration Audit 


PR: 

Problem Report (Form) 


RID: 

Review Item Discrepancy 
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8.0 GLOSSARY 

BASELINE: A configuration Identification document or a set of documents 

formally designated and fixed at a specific time during a Cl s life cycle. Baselines, 
plus approved changes from those baselines, constitute the current configuration 
identification. 

For configuration management there are typically three baselines, as follows: 

a) Functional Baseline. The initial approved functional configuration 
identification. 

b) Allocated Baseline. The initial approved allocated configuration 
identification. 

c) Product Baseline. The initial approved or conditionally approved 
product configuration identification. 

A fourth baseline is frequently utilized by engineering to establish the 
developmental configuration identification for a given product. The 
•developmental’ baseline is under engineering control and is not considered 
deliverable or official. 

CONFIGURATION: The functional and/or physical characteristics of hardware, 
software, or firmware as set forth in technical documentation and achieved in a 
product. 

CONFIGURATION CONTROL: The systematic evaluation, coordination, approval 
or disapproval, and implementation of all approved changes in the configuration of 
a Cl after formal establishment of its configuration identification. 

CONFIGURATION IDENTIFICATION: The current approved or conditionally 
approved technical documentation for a configuration item as set forth in 
specifications, drawings and associated lists, and the documents referenced therein. 

CONFIGURATION ITEM (Cl): An aggregation of hardware, software, firmware, or 
any of its discrete portions, which satisfies an end use function and is designated by 
the customer for configuration management. CIs may vary widely in complexity, 
size and type. 

CONFIGURATION STATUS ACCOUNTING: The recording and reporting of the 
information that is needed to manage configuration effectively, including a listing 
of the approved configuration identification, the status of proposed changes to 
configuration, and the implementation status of all approved changes. 
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10.0 APPENDIX 1 

10.1 IDENTIFICATION AND RELEASE PROCEDURES 

10.1.1 Introduction 

As the design of a product becomes more detailed, engineering begins to lay down 
the structure of the final product in terms of what configuration units are required, 
how many, and how they are to be organized. Once this data becomes relatively 
firm, configuration management is notified and the data tracked to ensure 
traceability to requirements, scheduled performance, and to ensure that the 
configuration items begin to enter the tracking data base in an organized manner. 
The vehicle used to obtain this data from engineering, enter it into the tracking data 
base, and ensure review of the final product prior to release is the Configuration 
Unit Identification and Release Notice (CUID). Refer to Figure 10.1.1-1, 
Configuration Identification and Release Notice. Figure 10.1.1-2, Configuration Unit 
Identification and Release Process depicts the process for the identification and 
release of internally developed or modified products. 

10.1.2 Identification 

10.1.2.1 Internally Developed Products 

Engineering initiates the identification process for internally developed products by 
identifying the unit on the CUID form and forwarding it to CM. The data supplied 
by engineering consists of the following: 

a) Program or project title 

b) Estimated release date 

c) Proposed nomenclature 

d) Specification number 

e) Title 

f) Next higher assembly 

g) Item type (either H/W or S/W) 

1) If the type is Hardware, the drawing type and size must be 
entered 

2) If the type is Software, the proposed Callname must be entered 

h) Security classification 

i) Description of the unit 

j) Where the unit is used if more than on just this project 

k) The engineer responsible for creating the Cl, and the date of the request 
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Prop ram 

Est. Rel. Date 

Part No. 

Rev. Level 

Nomen. 

Serial No. 

Snprification No. 

Title 




Vendor/Subcont. Cage Code 

Next Higher Assembly 

Item Type: 


H/W □ 


S/W □ 


DWG Type . 
Sheet Count . 
Callname 


Security Classification 
Description 


Engineer 

QA Rep. 

CCB Chair _ 
CCB Clerk _ 


Figure 10.1.1-1 


Sheet Size 

DWG Dash No. 
Rev. Level 
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Upon receipt of the CUID form, CM personnel shall: 

a) Assign the unit a Part Number in accordance with GHG CM policy 

b) Ensure that the proposed nomenclature meets GHG CM policy and 

requirements and make corrections as necessary 

c) Add the CAGE Code 

This data shall be entered into the CM tracking data base and the form shall be 
returned to engineering. When engineering has completed the development of the 
unit and the unit has successfully completed unit test, the remainder of the 
identification and release process shall be completed. 

Engineering shall complete the CUID form by entering the following data: 

a) Revision level, (if applicable) 

b) For Hardware units, the sheet count and drawing dash number 

c) For software units the revision level (if applicable) 

The form, together with a copy of the completed source code or drawing, shall be 
forwarded to Configuration Management for update to the data base and release 
review. 

During the release review process. Quality Assurance and the Configuration 
Manager review the data describing the unit and inspect the unit to ensure 
compliance with the applicable contractual requirements. If all requirements are 
met the release process described in paragraph 10.1.3 shall begin. If release 
requirements are not met, the forms and the units will be returned to engineering 
for repair. 

10.1.2.2 Numbering of Configuration Units 

Configuration Units shall be assigned unique identification numbers. Identification 
numbers shall not exceed 15 characters in length, including dashes, and shall not 
have blank spaces imbedded. Identification numbers shall consist of numbers, 
letters, or a combination thereof. The letters I, O, Q, S, X, and Z shall not be used. 
Numbers shall be Arabic and shall not include fractions, decimals, or Roman 
numerals. Parenthesis, (), asterisks, *, virgule, /, degree, and plus or minus symbols 
shall not be used. The revision level of the unit or part shall not be considered part 
of the identification number. 
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10.1.2.3 Documentation Numbering 

Documentation generated by GHG personnel as deliverables to the customer shall 
be uniquely identified. CM personnel shall assign identification numbers in 
accordance with the following schema: 

PROG. - DOC - SEQ 
I I I 

I I Sequence Number 

I I 

I Document Type 

I 

Program Name 

The Program Name is a six character field containing the program name or 
abbreviation. The Document Type is a six character field containing the 
abbreviation for the document. Appendix 2 to this plan contains a list of documents 
and their abbreviations. The Sequence Number is a six character numeric field 
containing the document number as assigned by CM. The sequence number shall be 
assigned for a log generated by CM. Each field will be separated a dash. The 
Revision and Change level fields shown in Appendix 2 are not considered part of 
the identification of the document. 

10.1.2.4 Vendor/Subcontractor Developed Products 

Upon receipt of materials from vendors or subcontractors, and prior to issuance for 
use, an inspection of all incoming material shall be conducted to ensure the 
completeness of the delivery. During the inspection, CM personnel shall record all 
part numbers and serial numbers for hardware items, specification numbers, 
document numbers, revision levels, and titles for all User's Guides, Operating 
Systems, etc. This data shall be entered into the CM tracking data base along with 
information regarding the vendor or subcontractor, including the CAGE code, 
address, contract number, and other information deemed pertinent to 
maintaining accurate and adequate identification and tracking of 
vendor/ subcontractor supplied items. The unit(s) shall then be released for use. 
Figure 10.1.2.4-1 CUID and Release of Vendor/Subcontractor Items depicts the 
process. 

This identification process, for either internally developed or vendor/subcontractor 
supplied units, will probably not be completed on the first pass because the design 
and development of a product can be extremely complex. Identification of 
configuration items at subordinate levels shall continue until the structure and 
content of the product is known. However, the release of units will not be held up 
pending the complete identification of each unit within the product. 


10-5 


RBSE-CMP-00001 



Start 


1 


Inventory of 
Received 
Items 
Performed 


Documents, 
Software 
Masters, and 
Dra wings, to 
Secure Storage 


CM Identifies 
Short Parts, 
Broken Items 


CM Updates 
Tracking Data 
Base 


Short/Broken 
Parts List to 
Contracts for 
Re-Order 


CM Issues 
RELEASE 
NOTICE with 
Short Parts 
List Attached 


CM Initiates 
CUID /RELEASE 
for Received 
Material 


CM Makes 
Copies of 
Unit 

Available for 
Use 


Figure 10.1.2.4-1 CUID and Release of Vendor/S ubcontractor Items 



Configuration Management Plan 


Appendix 1 


The result of the identification process is an indentured parts list that depicts the 
skeleton of the product, in its entirety, from the top down. 

10.1.3 Release 

Upon completion of the engineering drawing development effort, engineering shall 
update the CUID form with the sheet size and count for hardware units. The 
completed software configuration unit or hardware drawing, with the CUID form 
shall be forwarded to Configuration Management for review and release. The CM 
clerk shall assign a release notice number for the unit from a sequential log and 
schedule the unit for CCB review. 

The Configuration Control Board shall review the proposed release. If approved, 
the members of the CCB shall enter their signatures and the date of their approval 
in the appropriate spaces. The CM clerk shall update the data base with the 
approvals and dates. The unit itself shall be placed under configuration control, 
either in a CM-controlled data base for software units, or a secure drawing vault for 
hardware drawings. The clerk shall sign each form after the data base update and 
the securing of the units is completed. The form shall be placed on file. 

From this point on, all changes to the unit shall be placed under strict configuration 
control. 

10.1.3.1 Release of Vendor/Subcontractor Products 

Copies of vendor or subcontractor supplied software and documentation shall be 
released for use upon completion of inventory and inspection. CM personnel shall 
enter all data received in a timely manner. The originals shall be placed under CM 
control and shall not be issued except for the purposes of creating another usable 
copy This activity ensures the availability of a deliverable quantity and quality of 
the items purchased for use by GHG prior to delivery of the product to the customer. 

10.2 CHANGE CONTROL 

10.2.1 Introduction 

Changes occur for either evolutionary or revolutionary reasons. In an evolutionary 
change, either the performance or functional requirements for a unit have been 
modified by the customer or an enhancement to the performance or functional 
capabilities for the unit has been proposed by GHG personnel. In short, an 
evolutionary change can be typified as growth from one stage to its next logical stage. 
Revolutionary changes occur to repair a problem identified by either the customer 
or GHG’s Engineering or Quality personnel. 

If the unit has already been accepted by the customer, a Contract Change Proposal 
(CCP) is usually required to document the changes to the unit. If the unit has not 
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been formally accepted by the customer, a Discrepancy Report (DR), or a Review 
Item Discrepancy (RID) will suffice to initiate the change action needed to modify 
configuration units under configuration control. The data provided GHG on the 
CR, DR, or RID will be transferred to a Problem Report (PR) for tracking internally to 
GHG. The reporting documentation used to request a change to an individual 
configuration unit is an Engineering Change Request/Notice (ECR/N). 

Good business practice presupposes that the management team be involved in the 
review and approval-for-work process. This step ensures management visibility 
into the changes proposed for a configuration unit and provides the data 
management needs to make informed decisions relative to tradeoffs in cost, 
schedule, technical feasibility, etc. GHG uses a Problem Analysis (PA) form as a 
vehicle for providing management that data. 

To implement a change into a unit under Configuration Management control thus 
requires a reason for the change (a DR, RID, or CR), approval from Program 
Management in the form of an approved Problem Analysis form, and a vehicle for 

tracking the change, an ECR/N. 

In no instance will CM implement a change to configuration units under their 
control without having one of the problem reporting vehicles, authorization for 
change activity, and the Engineering Change Request/ Notice forms on file. 

The change control process requires six phases; initiation, analysis, change 
development, change review, change implementation, and change testing. During 
the initiation phase the problem or change is identified and the tracking of the 
repair or modification begins. During analysis, the possible courses of action are 
identified, including the cost in manhours, and the best path is recommended to 
program management. After program management review and approval of a 
particular course of action, change development within the engineering discipline 
occurs, followed quickly by change review at the GHG internal CCB level. If the 
proposed change package is approved it is implemented and the tracking of the 
reason for change and the change tracking vehicles themselves are closed out. 
Figure 10.2.1-1, Change Management Process Overview depicts the change process at 
a high level. 
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10.2.2 Initiation 

Discrepancy Reports, Change Requests, Review Item Discrepancies share common 
data This common data, describing the reason for a change, is entered on the 
Problem Report form. Refer to Figure 10.2.2-1, Problem Report Form. At the time 
of initiation, the following data, supplied by the originator, is required. 


a) Problem type, either DR, CR, or RID 

b) The DR, CR, or RID identification number 

c) A short title for the report 

d) The date the reason for change was discovered 

e) A description of the reason for change 

0 The name of the originator, phone number, and the company or 
agency, for whom they work 


The partially completed form is forwarded to GHG configuration management 
personnel who assign the report a unique Change Activity Number (CAN), enter 
the data into the tracking data base, initiate the Problem Analysis (PA) form with the 
problem number and CAN, and forward the package to the program manager for 

review. 

Assuming that changes are required, the program manager next assigns the work 
package a priority, an analyst or mid-level engineer, and a due date for the analysis 
of the problem. The package is forwarded to the analyst and program management 
informs CM of the priority, analyst, and due date. CM personnel add this data the 
tracking data base for change package tracking reports. Figure 10.2.2-2, Change 
Initiation and Analysis, provides a detailed picture of the initiation and analysis 
phases. 

10.2.3 Analysis 

During the analysis phase, the analyst determines what the cause of the discrepancy 
is, which units under CM control will require modification, how long the 
modifications will take, alternate solutions, if any, and the best course of action in 
his judgement. This data is entered on the Problem Analysis form and the package 
is then handed off to CM for data collection. CM then forwards the package to the 
program manager for analysis review. Refer to Figure 10.2.3-1, Problem Analysis 

Form. 

If the program manager agrees with the analysis of the problem and the proposed 
changes, the analysis review portion of the PA form is completed and the package is 
returned to CM. At this point, the change development phase is started. 
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10.2.4 Change Development 

When CM receives the work package from program management. Engineering 
Change Request/ Notices (ECR/Ns) are started for each of the units identified on the 
PA form. Refer to Figure 10.2.4-1, Engineering Change Request/ Notice. Figure 
10.2.4-2, Change Development, provides a detailed picture of the change 
development process. CM enters the following data for each ECR/N into the 
tracking data base: 

a) The problem identification number, and CAN from the Problem 
Report form 

b) A unique ECR/N number and the date the ECR/N was assigned 

c) The unit part number and the current revision or dash level 

d) The call name or title of the unit or specification 

e) The next higher assembly for the unit and the system the unit is part of 

At this point, CM searches the tracking data base to determine if any of the units 
requested for change are already under modification. If there is a conflict between 
the requested units, CM makes the data available to program management. 
Program management determines which package has the higher priority or the 
greater need for completion and informs CM. CM then either makes the unit 
available to the requesting engineer for change activity or places the ECR/N in a 
holding stack pending completion of the ECR/N currently in work. Copies of those 
units that are available for change are, with the change package, are forwarded to 
engineering. When the changes to the units in work are implemented, CM frees 
the current version and again, makes copies available to the engineer. 

At no time will CM issue the master, controlled copy, for modification. CM will not 
issue copies of units that are under modification to other engineers. This policy 
precludes multiple changes to the same unit under one ECR/N and serves to protect 
the engineer from wasting time and effort in modifying what will not be the most 
current version of the unit. 

Engineering then develops the modifications necessary to satisfy the problem or 
request for change. Information related to the changes are entered on the ECR/Ns 
as follows: 

a) Any related changes that are required to ensure proper 
implementation of the change. This would include such items as 
updates to the symbol dictionary prior to the update and compilation of 
the software unit 
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b) A brief description of the change, the engineer’s signature, and the date 
the change was temporarily loaded into a test environment 

Assuming GHG internal engineering testing of the modifications discloses no new 
problems and that the problem or request for change was satisfied, the engineer next 
completes a brief description of the entire change package on the Problem Report 
form and forwards the entire package, with the modified units, to CM for change 

review. 

10.2.5 Change Review 

Upon receipt of the change package, CM logs the package in for internal CCB review 
and notifies the members of the CCB that the package is available for inspection. 
The CCB members perform their inspections of the proposed change prior to the 
convening of the formal CCB. Figure 10.2.5-1, Change Review and Implementation, 
depicts the process for the review, approval or disapproval, and subsequent 
implementation of proposed changes to controlled software and documentation. 

At the time and place determined by CM, the CCB convenes and dispositions all 
packages scheduled. Their approval or disapproval with comments, of the package 
is noted in the minutes of the CCB. If the package is approved, the ECR/N forms are 
updated and CM updates the tracking data base with the new data. 

If any part of the package is disapproved the entire package is returned to 
engineering for repair and engineering development begins again. The policy of 
implementing only entire packages serves to preclude the implementation and test 
of partial changes, and reduces the possibility of GHG generating a bad product 
together with the resulting cost of unnecessary repairs. If the package requires CCB 
review at the next higher level above GHG, CM forwards it and makes the 
appropriate updates to the data base to schedule the package for review at that level. 
Assuming CCB approval, the package is ready for implementation. 

10.2.6 Change Implementation 

With approval for incorporation of modifications, CM forwards the ECR/Ns and 
changes to the appropriate agency for implementation. As the changes are 
incorporated, CM is notified and the newly updated unit is placed under CM 
control. Upon completion of this step, the ECR/Ns are closed out and a copy of the 
change package, including the Problem Report, Problem Analysis, the ECR/Ns, and 
the newly modified system or hardware is forwarded to the originator for retest. 

10.2.7 Change Testing 

Upon receipt of the change package, the originator tests the modified units in 
accordance with established acceptance test procedures. Assuming no new problems 
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were introduced and the package satisfies requirements, the originator completes 
the Disposition section of the problem report and returns it to CM. CM then 
updates the data base showing the completed status of the package and informs 
program management that the process is complete. 

10.2.8 Summary 

Part of Configuration Management's task is to provide management the visibility 
into change development. Placing CM at the focal point for all transactions 
regarding the identification and tracking of problems, the authorization for further 
efforts from engineering and the issuance of controlled copies of the units for 
modification and subsequent review and test, ensures that the data is made 
available because the status of any change is known by CM at all times. 
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20.0 APPENDIX II 

20.1 DOCUMENTATION IDENTIFICATION SCHEMA FOR GHG- 
DEVELOPED DOCUMENTATION 

PROG - DOC - SEQ - REV. _ CHG. _ 

I I I I I 

| ill Change Level (2 char., numeric) 

I I I I 

| I I Revision Level (2 char., alphabetic) 

1 I 1 

I I Sequence Number (6 char., numeric, CM-assigned) 

II 

I Document Type (6 char., alphabetic, from list below) 

I 

Program Title (6 char., alpha-numeric, may be abbreviation) 
ABBREVIATION 

1. ATP 

2. CIDR 

3. CIDS 

4. CCP 

5. CMAR 

6. CMP 

7. CRISD 

8. CSAR 

9. CSOM 

10. DEV 

11. DMP 

12. ECP 

13. FSM 

14. ICD 

15. IDD 

16. IRS 

17. ISD 

18. PID 

19. PMP 

20. RFP 

21. SCN 

22. SDD 


DOCUMENT & TYPE 

Acceptance Test Plan 

Configuration Item Development Record 

Critical Item Development Specification 

Contract Proposal or Contract Change Proposal 

Configuration Management Accounting Report 

Configuration Management Plan 

Computer Resources Integrated Support Document 

Configuration Status Accounting Report 

Computer System Operator's Manual 

Request for Deviation 

Data Management Plan 

Engineering Change Proposal 

Firmware Support Manual 

Interface Control Document 

Interface Design Document 

Interface Requirements Specification 

Integrated Support Document 

Prime Item Development Specification 

Program Management Plan 

Request for Proposal 

Specification Change Notice 

Software Design Document 
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DOCUMENTATION IDENTIFICATION SCHEMA FOR GHG-DEVELOPED 
DOCUMENTATION (CONTINUED) 

PROG - DOC - SEQ - REV. _ CHG. _ 

I I I I I 

| III Change Level (2 char., numeric) 

I I I I 

| I I Revision Level (2 char., alphabetic) 

I I I 

| I Sequence Number (6 char., numeric, CM-assigned) 

II . 

I Document Type (6 char., alphabetic, from list below) 

Program Title (6 char., alpha-numeric, may be abbreviation) 


ABBREVIATION 

DOCUMENT & TYPE 

23. 

SDDD 

Software Detailed Design Document 

24. 

SDP 

Software Development Plan 

25. 

SEM 

System Engineering Management Plan 

26. 

SPM 

Software Programmer's Manual 

27. 

SPS 

Software Product Specification 

28. 

SQA 

Software Quality Assurance Plan 

29. 

SRS 

Software Requirements Specification 

30. 

SSDD 

System / Segment Design Document 

31. 

SSS 

System / Segment Specification 

32. 

STD 

Software Test Description 

33. 

STLD 

Software Top Level Design Document 

34. 

STP 

Software Test Plan 

35. 

STPR 

Software Test Procedure 

36. 

STR 

Software Test Report 

37. 

SUM 

Software User’s Manual 

38. 

VDD 

Version Description Document 

39. 

WAV 

Request for Waiver 
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